(1) Field of the Invention
The present invention relates to the field of computer software development. More specifically, the present invention relates to a method and apparatus for controlling execution of a distributed computer application program.
(2) Art Background
Tools for debugging and profiling computer programs have become essential to the development of modern software applications. Debuggers facilitate error detection and correction, performance profilers generate timing profiles illustrating the location of execution bottlenecks and tracing tools generate histograms indicating the number of executions of a program's various procedures and the number of traversals of branches within the procedures.
Each of these tools have a common characteristic. They require code execution to be stopped or interrupted at certain points so that execution information can be gathered. A performance profiler, for example, might require a stop at the entry and exit of each procedure so that the time required for the procedure to be executed can be measured in a stopwatch-like fashion. In a tracing tool, a stop at the entry to each procedure might be required so that the tool can record the entry in a histogram. In a debugger, a user may specify certain break events, the detection of which is to result in halting (breaking) execution of the code being debugged. After execution breaks, the debugger user can examine execution information such as stack, variable and machine data. Since the ability to control the starting and stopping of code execution is fundamental to each of these software development tools, they are referred to collectively herein as controlled-execution tools.
For most computer programs, tools designed to control execution of program code in a single process are adequate. More and more modern applications, however, involve multiple local processes, multiple threads or multiple processes distributed across multiple machines. Such applications are said to be partitioned. In partitioned applications, debuggers and profilers directed to managing and examining the execution of a single process are often inadequate to meet a software developer's needs.
To illustrate the limitation of a single-process program development tool, consider a multiprocess database application. One process, a client process, might be developed to interact with a database user. The client process might display predesigned data-entry forms for receiving data input, receive query commands from the user instructing the client process to obtain information of interest, and perform numerous other user-interface operations. Another process, a server process, may act as gatekeeper to the data store itself. The server might receive requests from the client process and, in response, write to or read from the data store. Of course, the server might support multiple clients and provide other functions as well, such as maintaining data integrity, providing system security and optimizing database availability. One way in which the client process might communicate database query and update requests to the server process is via remote procedure calls. That is, procedure calls made by the client application requiring execution by the server application.
Consider what happens when a single-process debugger is used to debug a program containing a remote procedure call. At any time before the remote procedure call is made by the local process, breakpoints may be reached and execution information pertaining to the local process examined. After the remote procedure call is made, however, the execution of interest occurs in a remote process; a process over which the single-process debugger has no control. Until the remote procedure call is completed, the debugger, and therefore the software developer, is running blind. Execution of the remote procedure may not be halted at points of interest and execution information resulting from execution of the remote procedure may not be examined. Single process code coverage and performance profiling tools, which also require controlled execution, exhibit similar shortcomings in a multiprocess or distributed process environment.
One way in which software developers have attempted address this problem is to concurrently execute software development tools on each of the processes, caller and recipient, involved in the remote procedure call under test. This can be cumbersome, however, especially when the two processes under test are operating on separate machines. Furthermore, in some cases the recipient process is either created or awakened (e.g., from a suspended state) in response to the remote procedure call. In such cases it is difficult to launch or resume the process under test and launch a software development tool on that process simultaneously.
It is desirable, therefore, to provide a method for controlling execution of partitioned code without requiring separate development tools to be executed in each partition. Furthermore, it is desirable to make the partition transparent so that the development tool user is relieved from having to know where, or in what process, the code being evaluated is located. Finally, it is desirable to permit controlled execution of code residing in heterogeneous operating environments by removing machine and operating system dependent characteristics from the execution information being presented to the user.